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Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining services and signalling protocols applicable to 
Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to 
the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been 
produced under ETSI work item DTS/ECMA-00227. 

The present document specifies the Short Message Service. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document is contributed to ISO/IEC JTCl under terms of the fast-track procedure, for adoption as an 
ISO/IEC International Standard. 

The present document has been adopted by the ECMA General Assembly of June 2001. 
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1 Scope 

The present document specifies the Short Message Service (SMS). 

SMS enables a user to send and receive Short Messages (SMs) to and from another user. 

NOTE 1: This service is based on GSM 03.40. The Service Centre functionaHty described in the present document 
is equal to the frinctionality of a Service Centre in GSM 03.40. Thus it is only necessary to implement a 
QSIG interface and some interworking in the Service Centre in order to use it in the herein described 
network. 

NOTE 2: The Short Message Service is a special kind of basic service but is described in this document in the style 
of a supplementary service. 

Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. 
The present document contains the stage 1 and stage 2 specifications of SMS. The stage 1 specification (clause 6) 
specifies the service as seen by users of PISNs. The stage 2 specification (clause 7) identifies the functional entities 
involved in the service and the information flows between them. 



2 Conformance 

In order to confirm to the present document, a stage 3 standard shall specify signalling protocols and equipment 
behaviour that are capable of being used in a PISN which supports the service specified in the present document. This 
means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of 
clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard 
applies. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

ECMA-133: "Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) 
(International Standard ISO/IEC 11579-1)". 

ECMA-142: "Private Integrated Services Network (PISN) - Circuit Mode 64kbit/s Bearer Services - Service 
Description, Functional Capabilities and Information Flows (BCSD)". (International Standard ISO/IEC 11574). 

ECMA-155: "Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)". 

ECMA- 163: "Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - 
Name Identification Supplementary Services (NISD) (International Standard ISO/IEC 13864)". 

ECMA-241: "Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - 
Message Waiting Indication Supplementary Service (MWISD) (International Standard ISO/IEC 15505)". 

GTS GSM 03.38: "Digital cellular telecommunications system (Phase 2+) (GSM); Alphabets and language-specific 
information (GSM 03.38)". 
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ETSI TS 100 901: "Digital cellular telecommunications system (Phase 2+) (GSM); Technical realization of Short 
Message Service (SMS) Point-to-Point (PP) (GSM 03.40)". 

TS 101 032: "Digital cellular telecommunications systems (Phase 2+) (GSM); Compression algorithm for text 
messaging services (GSM 03.42)". 

GSM 04.1 1: "Digital cellular telecommunications system (Phase 2+) (GSM); Point-to-Point (PP) Short Message 
Service (SMS) support on mobile radio interface (GSM 04.1 1)". 

GSM 09.02: "Digital cellular telecommunications systems (Phase 2+) (GSM); Mobile Application Part (MAP) 
specification (GSM 09.02)". 

ETSI ETS 300 387 (1994): "Private Telecommunication Network (PTN); Method for the specification of basic and 
supplementary services". 

ITU-T Recommendation 1.1 12 (1993): "Vocabulary of terms for ISDNs". 

ITU-T Recommendaton 1.210 (1993): "Principles of telecommunication services supported by an ISDN and the means 
to describe them". 

ITU-T Recommendation Z. 100 (1999): "Specification and description language (SDL)". 



4 Definitions 

For the purpose of the present document, the following definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Basic Service: See ITU-T Recommendation 1.210. 

Private Integrated services Network eXchange (PINX): See ECMA-133. 

Private Integrated Services Network (PISN): See ECMA-133. 

Service: See ITU-T Recommendation 1.112. 

Signalling: See ITU-T Recommendation 1.112. 

Supplementary Service: see ITU-T Recommendation 1.210. 

User: SeeECMA-142. 

4.2 Other definitions 

NOTE: Further PDU elements are described in annex A. 

4.2.1 Command 

A Short Message data unit which enables the Sending User to request the Service Centre to perform a certain action, 
which might be related to a previously sent Short Message from the same Sending User. 

As far as acknowledging and delivery is concerned. Commands are treated like Short Messages. In the case of certain 
Commands a Status Report may be sent in response from the SC which contains the outcome of the action. 



ETSI 



ETSI TS 101 990 VI. 1.1 (2001-09) 



4.2.2 Message Centre 



The entity that activates or deactivates the Message Waiting Indication against the Receiving User as a resuh of the 
storage or retrieval of Short Messages. The Message Centre can serve as a sending, storing and receiving entity for 
Short Messages on behalf of the Sending and/ or the Receiving User. 

4.2.3 Message Centre Case 

This describes that either the Sending Users terminal or the Receiving Users terminal or both are not able to handle the 
procedures that are required by the SMS. In this case a Message Centre can act on behalf of these terminals. The 
procedures how a user can compose and retrieve SMS related information via a Message Centre are out of the scope of 
the present document. 

4.2.4 ScAlert 

Information provided to an SC that has previously initiated unsuccessful Short Message delivery attempt(s) to a specific 
Receiving User, that the Receiving User is now recognized to have recovered operation or to have memory available 
again. 

4.2.5 Service Centre (SC) 

A function within the network that receives Short Messages from Sending Users. The SC is responsible for the relaying 
and store-and-forwarding of these Short Messages to the Receiving Users. 

If a Receiving User is not able to receive a Short Message, the Service Centre has to store the Short Message and 
attempt to deliver the Short Message again at a later time. The Service Centre is responsible for a Short Message until it 
is successfully delivered to the Receiving User or the Validity Period expires. 

Depending on the implementation of Short Message Waiting Data the SC either repeats the delivery attempt 
automatically in certain intervals or attempts to deliver the Short Message upon reception of a ScAlert information. 

An SC may receive Commands from the Sending User and perform the requested actions. 

Additionally, the Service Centre may provide Status Reports to a Sending User. 

4.2.6 Short Message (SM) 

Data unit containing the Short-Message-Text and additional data necessary for the transmission of the Short-Message- 
Text from the Sending to the Receiving User. 



4.2.7 Short Message Waiting Data 



SMS user specific information containing address information of one or more SCs, which unsuccessfully attempted to 
deliver a Short Message to a Receiving User while the user was not able to receive the Short Message (e.g. did not have 
memory available or was not reachable). The Short Message Waiting Data is used to alert the SC when the Receiving 
User has memory available or is reachable again. 

4.2.8 Status Report 

Information optionally sent from the SC to the Sending User containing the status of a Short Message submitted to a 
Receiving User or the outcome of a Command submitted to an SC. A Status Report for a Command or a Short Message 
is sent from the SC to the Sending User if it has been requested in the Short Message or Command. 

4.2.9 Terminal Case 

This describes that either the Sending Users terminal or the Receiving Users terminal or both are able to handle the 
procedures that are required by the SMS. 
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Acronyms 



ANF 

FE 

PINX 

PISN 

FN? 

SC 

SCTS 

SDL 

SM 

SMS 

SMSC 

SMWD 

VP 



Additional Network Feature 

Functional Entity 

Private Integrated services Network eXchange 

Private Integrated Services Network 

Private Numbering Plan 

Service Centre 

Service-Centre-Time-Stamp 

Specification and Description Language 

Short Message 

Short Message Service 

Short Message Service Centre 

Short Message Waiting Data 

Validity Period 



6 SS-Short Message Service stage 1 specification 

6.1 Description 

6.1.1 General description 

The Short Message Service provides a means of sending messages of limited size point-to-point between network users. 
The provision of SMS makes use of a Service Centre which acts as a store-and-forward centre for Short Messages, i.e. 
all Short Messages are sent using a Service Centre which receives Short Messages from the Sending User, stores them 
and delivers them to the Receiving User. Thus the network needs to support the transfer of Short Messages between 
Sending User, Service Centre and Receiving User. 

The Sending User sends the Short Message to the Service Centre where the Short Message is stored. The Service Centre 
attempts to deliver the Short Message to the Receiving User. If a Short Message cannot be delivered within a specific 
time (Validity Period) the Service Centre deletes the Short Message. 

Other messages besides the user defined Short Messages can be sent using SMS: 

Status Reports inform the Sending User about the status of a previously sent Short Message or Command; 

Commands allow users to manipulate Short Messages already stored in a Service Centre or the behaviour of the 
Service Centre with regard to the Status Report procedure. 

NOTE: The functionality of the Service Centre in this specification is identical to the functionality of a Service 
Centre in GSM. 

6.1 .2 Qualifications on applicability to telecommunications services 

This service does not apply directly to any basic telecommunication service. 



6.2 



Procedures 



6.2.1 



Provision/withdrawal 



SMS may be provided after pre-arrangement with the service provider, or may be available generally to all users. SMS 
may be withdrawn on request of the user or for administrative reasons. 
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6.2.2 Normal procedures 

6.2.2.1 Activation/deactivation/registration/interrogation 

Not applicable. 

6.2.2.2 Invocation and operation 

All information shall be delivered by setting up a new call independent connection. Release of the call independent 
connection is in the responsibility of its initiator. 

6.2.2.2.1 Normal operation 

A Sending User shall be able to submit a Short Message to a Service Centre at any time, independently of whether or 
not there is a call in progress. An indication shall always be returned to the Sending User; either confirming that the SC 
received the Short Message or informing the Sending User that it was not possible to deliver the Short Message to the 
SC, including the reason why. 

A Sending User shall be able to submit a Command to a Service Centre at any time, independently of whether or not 
there is a call in progress. 

The Service Centre shall receive Commands from the Sending User and execute them. Upon reception of a Command 
the Service Centre shall execute the Command on the Short Message specified by the Short Message Number and the 
Originating-Address given in the Command information. An indication shall always be returned to the Sending User, 
either confirming the reception/ execution of the Command or indicating that the reception/ execution of the command 
failed, including the reason why. 

A Receiving User shall be able to receive a Short Message from a Service Centre at any time, independently of whether 
or not there is a call in progress. An indication shall always be returned to the SC; either confirming that the Receiving 
User received the Short Message, or indicating that the reception of the Short Message failed, including the reason why. 

If either a Short Message or a Command submitted to the Service Centre from a Sending User requests a Status Report, 
and the Status Report capabilities are included in the SC, it shall return one or more Status Reports to the Sending User. 
The Sending User shall be able to receive Status Reports from a Service Centre at any time, independently of whether 
or not there is a call in progress. An indication shall always be returned to the Service Centre, either confirming the 
reception of the Status Report or indicating that the reception failed, including the reason why. 

It shall be possible for the Sending User to send several correlated Short Messages, which together form a longer 
Message (Concatenated Short Message). 

NOTE: The acknowledging of a successful reception of a Short Message or a Status Report by the receiving 

entity does not imply that the Short Message or the Status Report has been displayed or in any other way 
delivered to the user. 

6.2.3 Exceptional procedures 

6.2.3.1 Activation/deactivation/interrogation 

Not applicable. 

6.2.3.2 Invocation and operation 

If the Service Centre is not able to receive a Short Message from the Sending User it shall return an indication to the 
Sending User containing the Failure-Cause. 

If the Service Centre is not able to receive/execute a command submitted from the Sending User it shall return an 
indication to the Sending User containing the Failure-Cause. 

If the Receiving User is not able to receive a Short Message delivered from the Service Centre the Receiving User shall 
return an indication to the Service Centre containing the Failure-Cause. 
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If the Sending User is not able to receive a Status Report from the Service Centre the Sending User shall return an 
indication to the Service Centre containing the Failure-Cause. 

If the Service Centre is not able to deliver a Short Message to a Receiving User because there is no memory available or 
the user is not reachable, the entity responsible for that Receiving User shall set an internal indication that a Service 
Centre attempted to deliver a Short Message to this user and store the address of that SC in the Short Message Waiting 
Data. When the Receiving User has memory available or is reachable again the entity shall send an ScAlert to the 
Service Centre, containing the address of the Receiving User and upon reception of an ScAlert confirmation delete the 
SC address from the SMWD list. 

The implementation of the Short Message Waiting Data is optional. If it is not implemented it is up to the SC to repeat 
the delivery attempt periodically until the Validity Period expires. 

6.3 Interactions with other Supplementary Services/ Additional 
Network Features 

Interactions with other supplementary services and ANFs for which PISN standards were available at the time of the 
present document are specified below. 

6.3.1 Calling Line Identification Presentation (SS-CLIP) 

No interaction. 

6.3.2 Connected Line Identification Presentation (SS-COLP) 

No interaction. 

6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR) 

No interaction. 

6.3.4 Calling Name Identification Presentation (SS-CNIP) 

No interaction. 

6.3.5 Calling/Connected Name Identification Restriction (SS-CNIR) 

No interaction. 

6.3.6 Connected Name Identification Presentation (SS-CONP) 

No interaction. 

6.3.7 Completion of Calls to Busy Subscriber (SS-CCBS) 

No interaction. 

6.3.8 Completion of Calls on No Reply (SS-CCNR) 

No interaction. 

6.3.9 Call Transfer (SS-CT) 

No interaction. 
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6.3.10 Call Forwarding Unconditional (SS-CFU) 

Call forwarding shall not apply for Short Message Service. 

6.3.1 1 Call Forwarding Busy (SS-CFB) 

Call forwarding shall not apply for Short Message Service. 

6.3.12 Call Forwarding No Reply (SS-CFNR) 

Call forwarding shall not apply for Short Message Service. 

6.3.13 Call Deflection (SS-CD) 

Call deflection shall not apply for Short Message Service. 

6.3.14 Path Replacement (ANF-PR) 

No interaction. 

6.3.15 Call Offer (SS-CO) 

No interaction. 

6.3.16 Call Intrusion (SS-CI) 

No interaction. 

6.3.17 Do Not Disturb (SS-DND) 

Do Not Disturb shall not apply for Short Message Service. 

6.3.1 8 Do Not Disturb Override (SS-DNDO) 

No interaction. 

6.3.19 Advice of Charge (SS-AOC) 

No interaction. 

6.3.20 Recall (SS-RE) 

No interaction. 

6.3.21 Call Interception (ANF-CINT) 

Call Interception shall not apply for Short Message Service. 

6.3.22 Transit Counter (ANF-TC) 

No interaction. 

6.3.23 Route Restriction Class (ANF-RRC) 

No interaction. 
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6.3.24 Message Waiting Indication (SS-MWI) 

The Message Centre may act as a sending entity for Short Messages and Commands and as a storage entity for Short 
Messages and shall indicate the reception of new Short Messages to the Receiving User. 

6.3.25 Wireless Terminal Location Registration (SS-WTLR) 

No interaction. 

NOTE: A Short Message may be directed to the new location. 

6.3.26 Wireless Terminal Mobility Incoming Call (ANF-WTMI) 

No interaction. 

6.3.27 Wireless Terminal Mobility Outgoing Call (ANF-WTMO) 

No interaction. 

6.3.28 Authentication of a WTM user (SS-WTAT) 

No interaction. 

6.3.29 Authentication of the PISN (SS-WTAN) 

No interaction. 

6.3.30 Private User Mobility Incoming Call (ANF-PUMI) 

No interaction. 

6.3.31 Private User Mobility Outgoing Call (ANF-PUMO) 

No interaction. 

6.3.32 Private User Mobility Registration (SS-PUMR) 

No interaction. 

6.3.33 Common Information (ANF-CMN) 

No interaction. 

6.3.34 Call Priority Interruption (Protection) (SS-CPI(P)) 

No interaction. 

6.3.35 Single Step Call Transfer (SS-SSCT) 

No interaction. 

6.3.36 Simple Dialog (SS-SD) 

No interaction. 
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6.3.37 Call Identification and Call Linkage (ANF-CIDL) 

No interaction. 

6.4 Interworking considerations 

A Service Centre may be connected to other networks than a PISN and receive Short Messages from and send Short 
Messages to the other networks. 

6.5 Overall SDL 
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Figure 1 : Overall SDL (sheet 1 of 3) 
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Figure 2: Overall SDL (sheet 2 of 3) 
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Figure 3: Overall SDL (sheet 3 of 3) 
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Short Message Service stage 2 description 



7.1 



Functional model 



7.1 .1 Functional model description 

The functional model shall comprise the following Functional Entities (FEs): 

FEl Short Message Sending User Agent 

FE2 Sending User Service Control Entity 

FE3 Service Centre Control Entity 

FE4 Receiving User Service Control Entity 

FES Short Message Receiving User Agent 

FE6 Sending User Message Centre 

FE7 Receiving User Message Centre 
The following relationships shall exist between these FEs: 

ra between FEl and FE2 

rb between FE2 and FE3 and FE6 and FE3 

re between FE3 and FE4 and FE4 and FE7 

rd between FE4 and FES 
Figure 4 shows these FEs and relationships. 



FEl 


ra 


FE2 


rb 


FES 


re 


FE4 


rd 


FES 




/rb 
















re 






FE6 






FE7 















Figure 4: Functional Entities 

7.1 .2 Description of Functional Entities 

7.1 .2.1 Short Message Sending User Agent, FE1 

This Functional Entity: 

• submits the Short-Message-Text and optional elements to FE2; 

• submits Command elements to FE2; 

• receives Submit Confirmations for sent SMs or Commands from FE2; 

• receives Status Reports from FE2; 
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• submits Delivery Confirmation elements for received Status Reports to FE2. 

7.1 .2.2 Sending User Service Control Entity, FE2 

This Functional Entity: 

• composes Short Messages using the Short-Message-Text and optional elements from FBI, adding additional 
elements if necessary, and sends them to FE3; 

• composes Commands using the elements from FBI, adding additional elements if necessary, and sends them to 
FB3; 

• receives Submit Confirmations and Status Reports from FB3; 

• sends Submit Confirmations and Status Reports to FBI; 

• receives Delivery Confirmation elements from FBI and sends them to FB3. 

7.1 .2.3 Service Centre Control Entity, FES 

This Functional Bntity: 

• receives Short Messages from FB2 or FB6, stores them and attempts to deliver them to FB4 until the Validity 
Period expires; 

• composes and sends Submit Confirmations and Status Reports to FB2 or FB6; 

• deletes Short Messages when the Validity Period is expired; 

• receives Commands from FB2 or FB6 and executes them on the Short Messages given in the Command Data if 
they are still available in the SC; 

• receives Delivery Confirmations from FB4; and 

• optionally, receives SC-Alerts from FE4. 

7.1 .2.4 Receiving User Service Control Entity, FE4 

This Functional Bntity: 

• receives Short Messages from FB3; 

• sends the Short-Message-Text and optional elements to FB5; or 

• sends the Short Messages to FE7; 

• receives Delivery Confirmations from FES or FE7 and sends them to FE3; and 
in the Terminal Case, optionally: 

• keeps a list of SC (SMWD) which attempted to deliver a Short Message while the Receiving User was not 
reachable; and 

• sends Sc Alert messages to FE3; or 
in the Message Centre Case, optionally: 

• receives Sc Alerts from FE7 and sends them to FE3. 



£75/ 



19 ETSI TS 101 990 VI. 1.1 (2001-09) 

7.1 .2.5 Short Message Receiving User Agent, FES 

This Functional Entity: 

• receives Short-Message-Text and optional elements from FE4; 

• submits Delivery Confirmation elements to FE4; 

• delivers the Short Message to the Receiving User. 

7.1 .2.6 Sending User Message Centre, FE6 

This Functional Entity: 

• receives Short Message or Command elements; 

• composes and sends Short Messages to FE3; 

• composes and sends Commands to FE3; 

• receives Submit Confirmations from FE3; 

• receives Status Reports from FE3; 

• sends Delivery Confirmations to FE3. 

7.1.2.7 Receiving User Message Centre, FE7 

This Functional Entity: 

• receives Short Messages from FE4 and stores them; 

• submits Delivery Confirmations to FE4; 

• indicates the reception of a new Short Message to the Receiving User; and 
in the Message Centre Case, optionally: 

• keeps a list of SC (SMWD) which attempted to deliver a Short Message while the Receiving User was not 
reachable and sends SC-Alert messages to FE4. 

7.1 .3 Relationship of functional model to Basic Call functional model 

No relationship between functional model and basic call functional model. 

7.2 Information flows 

7.2.1 Definition of information flows 

In the tables listing the elements in information flows, the column headed "Request" indicates which of these elements 
are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed 
"Confirm" (confirmed information flows only) indicates which of these elements are mandatory (M) and which are 
optional (O) in a response/confirmation information flow. 

Further descriptions of the PDU elements can be found in annex A. 



£75/ 



20 



ETSI TS 101 990 VI. 1.1 (2001-09) 



7.2.1.1 



ra SmsSubmit 



ra_SmsSubmit is a confirmed information flow across ra from FEl to FE2 used to submit Short Message elements from 
the Short Message Sending User Agent to the Sending User Service Control Entity. Table 1 lists the elements within the 
ra_SmsSubmit information flow. 

Table 1 : Contents of ra SmsSubmit 



Element 


Request 


Confirm 


Receiving User's number 


M 




Sending User's number 







Short IVIessage Reference 







Protocol Identifier 








Status-Report-Request 







Reply-Path 







Reject-Duplicates 







Class 








Compressed 








Short-Message-Text 


M 


(Note) 


Validity-Period 







User Data Header 





(Note) 


SMSC Control Parameters 








Service-Centre-Time- Stamp 




M 


NOTE: This element is only available in an SmsSubmit 
response/ confirmation for use by the Service 
Centre. 



7.2.1.2 



rb SmsSubmit 



rb_SmsSubmit is a confirmed information flow across rb from FE2 to FE3 or from FE6 to FE3 used to submit the Short 
Message from the Sending User Service Control Entity or Sending User Message Centre, respectively, to the Service 
Centre Entity. Table 2 lists the elements within the rb_SmsSubmit information flow. 

Table 2: Contents of rb SmsSubmit 



Element 


Request 


Confirm 


Receiving User's number 


M 




Sending User's number 


M 




Short Message Reference 


M 




Protocol Identifier 


M 





Status-Report-Request 


M 




Reply-Path 


M 




Reject-Duplicates 


M 




Class 








Compressed 


M 





Short-Message-Text 


M 


(Note) 


Validity-Period 







User Data Header 





(Note) 


Service-Centre-Time-Stamp 




M 


NOTE: This element is only available in an SmsSubmit 
response/ confirmation for use by the Service 
Centre. 
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7.2.1.3 



rc SmsDeliver 



rc_SmsDeliver is a confirmed information flow across rc fi-om FE3 to FE4 or fi-om FE4 to FE7 used to submit the Short 
Message fi^om the Service Centre Entity to the Receiving User Service Control Entity and fi^om the Receiving User 
Service Control Entity to the Receiving User Message Centre. Table 3 lists the elements within the rc_SmsDeliver 
information flow. 

Table 3: Contents of rc SmsDeliver 



Element 


Request 


Confirm 


Sending User's number 


M 




Receiving User's number 


M 




Protocol Identifier 


M 





Service-Centre-Time-Stamp 


M 




Priority 


M 




IVIore-IVIessages-to-Send 


M 




Status-Report-Indication 


M 




Reply-Path 


M 




Class 








Compressed 


M 





Short-Message-Text 


M 


(Note) 


User Data Header 





(Note) 


Sending User's name 







NOTE: This element is only available in an 

SmsDeliver response/ confirmation for use by 
the Receiving User entity. 



7.2.1.4 



rd SmsDeliver 



rd_SmsDeliver is a confirmed information flow across rd from FE4 to FES used to submit the Short Message from the 
Receiving User Service Control Entity to the Short Message Receiving User Agent. Table 4 lists the elements within the 
rd_SmsDeliver information flow. 

Table 4: Contents of rd SmsDeliver 



Element 


Request 


Confirm 


Sending User's number 


M 




Receiving User's number 







Protocol Identifier 








Service-Centre-Time- 
Stamp 







Priority 







More-Messages-to-Send 







Status-Report-Indication 







Reply-Path 







Class 








Compressed 








Short-IVIessage-Text 


M 


(Note) 


User Data Header 





(Note) 


Sending User's name 







NOTE: This element is only available in an 

SmsDeliver response/ confirmation for use 
by the Receiving User entity. 
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7.2.1.5 



ra_SmsStatus Report 



ra_SmsStatusReport is a confirmed information flow across ra from FE2 to FEl used to submit a Status Report from the 
Sending User Service Control Entity to the Short Message Sending User Agent. Table 5 lists the elements within the 
ra_SmsStatusReport information flow. 

Table 5: Contents of ra_SmsStatusReport 



Element 


Request 


Confirm 


Short Message Reference 


0(Note1) 




Service-Centre-Time-Stamp 


M 




Discliarge-Time 


M 




Receiving User's number 


M 




Destination Address 


M 




Status 


M 




Priority 







IVlore-IVIessages-to-Send 







Status-Report-Qualifier 







Receiving User's Name 







Protocol Identifier 








Class 








Compressed 








Short-Message-Text 





(Note 2) 


User Data Header 





(Note 2) 


NOTE 1 : Where the SmsStatusReport is the result of an 
SmsCommand and the Command Type was an 
Enquiry, the Short Message Reference returned in 
the SmsStatusReport shall be the Short Message 
Number which was sent in the SmsCommand (i.e. 
the Short Message Reference of the previously 
submitted Short Message to which the Enquiry 
refers). 

NOTE 2: This element is only available in an 

SmsStatusReport response/ confirmation for use 
by the Receiving User entity. 
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7.2.1.6 



rb_SmsStatus Report 



rb_SmsStatusReport is a confirmed information flow across rb from FE3 to FE2 or from FE3 to FE6 used to submit a 
Status Report from the Service Centre Entity to the Sending User Service Control Entity and from the Service Centre 
Entity to the Sending User Message Centre. Table 6 lists the elements within the rb_SmsStatusReport information flow. 

Table 6: Contents of rb_SmsStatusReport 



Element 


Request 


Confirm 


Short Message Reference 


M(Note1) 




Service-Centre-Time-Stamp 


M 




Discharge-Time 


M 




Receiving User's address 


M 




Destination Address 


M 




Status 


M 




Priority 


M 




More-IVIessages-to-Send 


M 




Status-Report-Qualifier 


M 




Receiving User's Name 







Protocol Identifier 








Class 








Compressed 








Short-Message-Text 





(note 2) 


User Data Header 





(note 2) 


NOTE 13: Where the SmsStatusReport is the result of an 
SmsCommand and the Command Type was an 
Enquiry, the Short Message Reference returned 
in the SmsStatusReport shall be the Short 
Message Number which was sent in the 
SmsCommand (i.e. the Short Message Reference 
of the previously submitted Short Message to 
which the Enquiry refers). 

NOTE 14: This element is only available in an 

SmsStatusReport response/ confirmation for use 
by the Receiving User entity. 



7.2.1.7 



ra SmsCommand 



ra_SmsCommand is a confirmed information flow across ra from FEl to FE2 used to transfer a Command from the 
Short Message Sending User Agent to the Sending User Service Control Entity. Table 7 lists the elements within the 
ra_SmsCommand information flow. 

Table 7: Contents of ra SmsCommand 



Element 


Request 


Confirm 


Receiving User's address 


M 




Short Message Reference 







Short Message Number 


M 




Protocol Identifier 


M 





Command-Type 


M 




Command-Data 







Status-Report-Request 







Service-Centre-Time-Stamp 




M 


Short-Message-Text 




(Note) 


Class 







Compressed 







User Data Header 




(Note) 


NOTE 15: This element is only available in an 

SmsCommand response/ confirmation for 
use by Service Centre. 
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7.2.1.8 



rb SmsCommand 



rb_SmsCommand is a confirmed information flow across rb from FE2 to FE3 or FE6 to FE3 used to transfer a 
Command from the Sending User Service Control Entity to the Service Centre Entity and from the Sending User 
Message Centre to the Service Centre Control Entity, respectively. Table 8 lists the elements within the 
rb_SmsCommand information flow. 

Table 8: Contents of rb SmsCommand 



Element 


Request 


Confirm 


Receiving User's address 


M 




Short IVIessage Reference 


M 




Short IVIessage Number 


M 




Protocol Identifier 


M 





Command-Type 


M 




Command-Data 







Status-Report-Request 







Service-Centre-Time-Stamp 




M 


Short-IVIessage-Text 




(Note) 


Class 







User Data Header 




(Note) 


Compressed 







NOTE: This element is only available in an 

SmsCommand response/ confirmation for use 
by Service Centre. 



7.2.1.9 



rd ScAlert 



rd_ScAlert is a confirmed information flow across rd from FES to FE4 used to transfer a ScAlert from the Short 
Message Receiving User Agent to the Receiving User Service Control Entity. Table 9 lists the elements within the 
rd_ScAlert information flow. 

Table 9: Contents of rd ScAlert 



Element 


Request 


Confirm 


Sending User's number 









7.2.1.10 



re ScAlert 



rc_ScAlert is a confirmed information flow across re from FE4 to FE3 or from FE7 to FE4 used to transfer a ScAlert 
from the Receiving User Service Control Entity to the Service Centre Entity and from the Receiving User Message 
Centre to the Receiving User Service Control Entity, respectively. Table 10 lists the elements within the rc_Sc Alert 
information flow. 

Table 10: Contents of re ScAlert 



Element 


Request 


Confirm 


Sending User's number 


M 


M 
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7.2.1.11 



smsDeliverError 



smsDeliverError is an unconfirmed information flow across re from FE4 to FE3 and rd from FES to FE4 or re from FE7 
to FE4 used to transfer an error indication due to the Short Message Receiving User Agent or the Receiving User 
Message Centre not being able to save a received rd_SmsDeliver/ rc_SmsDeliver. Table 1 1 lists the elements within the 
smsDeliverError information flow. 

Table 11 : Contents of smsDeliverError 



Element 


Request 


failureCause 


M 


protocolldentifier 





userDataHeader 


(Note) 


class 





compressed 





shortMessageText 


(Note) 


scAddressSaved 


M 


NOTE: This element is only available in 
an smsDeliverError request for 
use by the Receiving User 
entity. 



7.2.2 Information flow sequences 

A stage 3 standard for SS-SMS shall provide signalling procedures in support of the information flow sequences 
specified in the figures. In addition, signalling procedures should be provided to cover sequences arising from error 
situations, interactions with Basic Calls, interactions with other supplementary services, different topologies etc. 

Within a column representing an SS-SMS Functional Entity, the numbers refer to Functional Entity actions listed in 
clause 7.3. 
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7.2.2.1 Submission of a Short IVIessage 

Figure 5 shows in generic form the information flow sequence for submission of a Short Message when in the case 
when the Short Messages are stored in and sent from a Terminal. 



FE1 



101 



102 




ra 



FE2 



ra SmsSubmit 



con/res 



201 



202 



rb 



rb_SmsSubmit 
req/ind 



rb_SmsSubmit 

-< 

con/res 




rd 



FES 



rd SmsDeliver 
> 

req/ind 



rd SmsDeliver 



con/res 



501 



Figure 5: Information flow sequence for Short Message Transfer, Terminal-case 
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Figure 6 shows in generic form the information flow sequence for submission of a Short Message from FE6 to FE7. 




rb 



601 



602 



rb_SmsSubmit 
req/ ind 




-rc- 




rc 



,rb SmsSubmit 



CO n/res 



304 



302 



303 



re SmsDeliver 



req/ind 



re SmsDeliver 



eon/res 



403 



404 




re SmsDeliver 
— > 

req/ind 

rc_SmsDeliver 
t 

con/res 



701 



Figure 6: Information flow sequence for Short Message transfer - Message-Centre-case 

7.2.2.2 Delivery of a Status Report 

Figure 7 shows in generic form the information flow sequence for the submission of a Status Report from FE3 to FEl. 

rd 



FEl 



103 



FE2 



ra_SmsStatusReport 



req/ind 
ra_SmsStatusReport 

res/con 



203 



rb_SmsStatusReport 

K- 

req/ind 



204 



rb 



FE3 



rb_SmsStatusReport 



res/con 



305 



306 



FE4 



FES 



Figure 7: Information flow sequence for Status Report Transfer - Terminal-case 
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Figure 8 shows in generic form the information flow sequence for the submission of a Status Report from FE3 to FE6. 





171? K 




rb 


FE3 




re 




PF4 


rd 




171? C 


















603 


M 


rb SmsStatusReport 


307 
308 


















req/ind 
rb_SmsStatusReport 










res/con 



Figure 8: Information flow sequence for Status Report Transfer - Message-Centre-case 
7.2.2.3 Transfer of an SmsCommand 

Figure 9 shows in generic form the information sequence flow for the transfer of an SmsCommand from FEl to FE3. 



FE1 



104 



105 



ra 



FE2 



j]a_SmsCommarid 
req/ind 



ra SmsCommand 



res/con 



rb 



FE3- 



205 



206 



rb SmsCommand 



req/ind 



i:b_SmsCommand 
res/con 



309 



re 



FE4 



rd 



FES 



Figure 9: Information flow sequence for Command Transfer - Terminal-case 
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Figure 10 shows in generic form the information flow sequence for the submission of a Command from FE6 to FE3. 



FE6 



rb 



FES 



604 



605 



rb SmsCommand 



req/ind 



rb_SmsCommand 

K 

res/con 



310 



re 



FE4 



rd 



FES 



Figure 10: Information flow sequence for Command Transfer - Message-Centre-case 

7.2.2.4 Unsuccessful Transfer of an SmsDeliver and following transfer of an ScAlert 

Figure 1 1 shows in generic form the information flow sequence for the transfer of an ScAlert from FE4 to FE3. 



FE1 



ra 



FE2 



rb 



FES 



302 



311 



312 



re 



FE4 



re SmsDeliver 



req/ind 



re SmsDeliverError 



req/ind 



re SeAlert 



req/ind 



re ScAlert 



res/con 



401 



req/ind 



rd_SmsDeliverError 

K 

req/ind 



405 



406 



407 



rd 



FES 



rd SmsDeliver 



502 



Figure 1 1 : Information flow sequence for ScAlert Transfer - Terminal-case 
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Figure 12 shows in generic form the information flow sequence for the transfer of an Sc Alert from FE7 to FE3. 



FE1 



ra 



FE2 



rb 



FES 



re SmsDeliver _ 

302 P-= -^ 

req/ind 



311 <- 



312 



re 



FE4 



re smsDeliverError 



req/ind 



_rc^ScAlert 
req/ind 



rc^ScAlert_ 
res/con 



403 



408 



409 



410 



re 



FE7 



re_SmsDeliver 
req/ind 

re_SmsDeliverError 

< 

req/ind 



re_SeAlert 
req/ind 



rc_ScAlert 
res/con 



702 



703 



704 



Figure 12: Information flow sequence for ScAlert Transfer - Message-Centre-case 



7.3 Functional Entity actions 



7.3.1 Functional Entity actions of FE1 

101 Send ra_SmsSubmit request/indication to FE2 as received from the user. 

102 Receive ra_SmsSubmit response/confirmation from FE2 and deliver it to the user. 

103 Receive ra_SmsStatusReport request/indication from FE2 and deliver it to the user. Send 
ra_SmsStatusReport response/confirmation to FE2. 

104 Send ra_SmsCommand request/indication to FE2 as received from the user. 

105 Receive ra_SmsCommand response/confirmation from FE2 and deliver it to the user. 
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7.3.2 Functional Entity actions of FE2 



201 Receive ra_SmsSubmit request/indication from FEl, add additional elements if necessary and send 
rb_SmsSubmit request/indication to FE3. 

202 Receive rb_SmsSubmit response/confirmation from FE3 and send ra_SmsSubmit 
response/confirmation to FEl. 

203 Receive rb_SmsStatusReport request/indication from FE3, check the elements and send 
ra_SmsStatusReport request/indication to FEl. 

204 Receive ra_SmsStatusReport response/confirmation from FEl and send rb_SmsStatusReport 
response/confirmation to FE3. 

205 Receive ra_SmsCommand request/indication from FEl, add additional elements if necessary and 
send rb_SmsCommand request/indication to FE3. 

206 Receive rb_SmsCommand response/confirmation from FE3 and send ra_SmsCommand 
response/confirmation to FEl. 



7.3.3 Functional Entity actions of FE3 



301 Receive rb_SmsSubmit request/indication from FE2, check if parameters are correct and store the 
Short Message. Send rb_SmsSubmit response/confirmation to FE2. 

302 Compose rc_SmsDeliver request/indication message using the stored Short Message data and send 
it to FE4. 

303 Receive rc_SmsDeliver response/confirmation from FE4; this may trigger the sending of 
rb_Sms Status Report (see action 305). 

304 Receive rb_SmsSubmit request/indication from FE6, check if parameters are correct and store the 
Short Message. Send rb_SmsSubmit response/confirmation to FE6. 

305 If the user requested a Status Report in a previously sent SmsSubmit or SmsCommand then 
compose rb_SmsStatusReport request/indication message and send it to FE2. 

306 Receive rb_SmsStatusReport response/confirmation from FE2. 

307 If the user requested a Status Report in a previously sent SmsSubmit or SmsCommand then 
compose rb_SmsStatusReport request/indication message and send it to FE6. 

308 Receive rb_SmsStatusReport response/confirmation from FE6. 

309 Receive rb_SmsCommand request/indication from FE2 and action it on the Short Message 
identified by the elements in the command. Send rb_SmsCommand response/confirmation to FE2. 

310 Receive rb_SmsCommand request/indication from FE6 and action it on the Short Message 
identified by the elements in the command. Send rb_SmsCommand response/confirmation to FE6. 

311 Receive rc_SmsDeliverError request/indication from FE4, this may trigger the sending of 
rb_Sms Status Report (see action 305). 

312 Receive rc_Sc Alert request/indication from FE4 and send rc_Sc Alert response/confirmation to 
FEi4. If there are Short Messages or Status Reports waiting to be delivered to this Receiving User 
invoke delivery procedure (see action 302). 
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7.3.4 Functional Entity actions of FE4 



401 Receive rc_SmsDeliver request/indication from FE3, check if elements are correct and send 
rd_SmsDeliver request/indication to FES. 

402 Receive rd_SmsDeliver response/confirmation from FES and send rc_SmsDeliver 
response/confirmation to FE3. 

403 Receive rc_SmsDeliver request/indication from FE3, check if elements are correct and send 
rc_SmsDeliver request/indication to FE7. 

404 Receive rc_SmsDeliver response/confirmation from FE7 and send rc_SmsDeliver 
response/confirmation to FE3. 

405 Receive rd_SmsDeliverError request/indication from FES and send rc_SmsDeliverError 
request/indication to FE3, optionally, save Sc-Address if not saved already. 

406 Send rc_ScAlert request/indication to FE3 (only in Terminal Case). 

407 Receive rc_ScAlert response/confirmation from FE3 (only in Terminal Case). 

408 Receive rc_SmsDeliverError request/indication from FE7 and send rc_SmsDeliverError 
request/indication to FE3. 

409 Receive rd_ScAlert request/indication from FE7, add additional elements if necessary, and send 
rc_Sc Alert request/indication to FE3. 

410 Receive rc_Sc Alert response/confirmation from FE3 and send rd_Sc Alert response/confirmation 
to FE7. 

7.3.5 Functional Entity actions of FES 

501 Receive rd_SmsDeliver request/indication from FE4, deliver the Short Message to the user and 
send rd_SmsDeliver response/confirmation to FE4. 

502 Receive rd_SmsDeliver request/indication from FE4. If the received Short Message cannot be 
saved, then send rd_SmsDeliverError request/indication to FE4. 

7.3.6 Functional Entity actions of FE6 

601 On request of the user send rb_SmsSubmit request/ indication to FE3. 

602 Receive rb_SmsSubmit response/ confirmation from FE3 and indicate result to the user. 

603 Receive rb_SmsStatusReport request/indication from FE3 and indicate it to the user. Send 
rb_Sms Status Report response/confirmation to FE3. 

604 On user request send rb_SmsCommand request/indication to FE3. 

605 Receive rb_SmsCommand response/confirmation from FE3 and indicate result to the user. 



7.3.7 Functional Entity actions of FE7 



701 Receive rc_SmsDeliver request/indication from FE4, store the Short Message if possible, indicate 
the reception of the new message to the user and send rc_SmsDeliver response/confirmation to 
FE4. 

702 Receive rc_SmsDeliver request/indication from FE4. If it is not possible to store the Short 
Message send rc_SmsDeliver Error request/indication to FE4 and optionally, save SC-Address if 
not saved already. 

703 On an internal indication send an rc_ScAlert request/indication to FE4. 

704 Receive an rc_ScAlert response/confirmation from FE4. 
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7.4 Functional Entity behaviour 



The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and 
received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in 
ITU-T Recommendation Z. 100. 

7.4.1 Behaviour of FE1 

Figure 13 shows the normal behaviour of FEl. Output signals to the left and input signals from the left represent 
primitives to and from the Sending User. Output signals to the right and input signals from the right represent 
information flows to and from FE2. 
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Send_SM_Request 

from 

Sending User 



ra_SmsSubmit 
req/ind 
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Request 
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Sending User 



ra_SmsCommand 
req/ind 



104 SmsStatusReport 

req/ind 



SmsStatusReport 
resp/conf 



103 



FE1_Submit 
lnvol<ed 



ra_smsSubmit 
resp/conf 



Result Indication 

to the 

Sending User 



102 



FE1_Command 
Invoked 



ra_smsCommand 
resp/conf 



Result Indication 

to the 

Sending User 



105 



Result Indication 

to the 

Sending User 



FE1 Idle 



Figure 13: SMS, SDL for Functional Entity 1 



£75/ 



34 



ETSI TS 101 990 VI. 1.1 (2001-09) 



7.4.2 Behaviour of FE2 

Figure 14 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent 
information flows to and from PEL Output signals to the right and input signals from the right represent information 
flows to and from FE3. 



FE2 Idle 



ra_SmsSubmit 
req/ind 
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rb_SmsSubmit 
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ra_SmsCommand 
req/ind 
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if necessary 



rb_SmsCommand 
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FE2_SR 
Invoked 



203 



FE2_Submit 
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rb_SmsSubmit 
resp/conf 



ra_SmsSubmit 
resp/conf 
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FE2_Command i 
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rb_SmsCommand 
resp/conf 



raSmsCommand 
resp/conf 



206 



SmsStatusReport 
resp/conf 



add elements 
if necessary 



204 



SmsStatusReport 
resp/conf 



FE2 Idle 



Figure 14: SMS, SDL for Functional Entity 2 

7.4.3 Behaviour of FES 

Figure 15 and figure 16 show the normal behaviour of FE3. Output signals to the left and input signals from the left 
represent information flows to and from FE2 or FE6. Output signals to the right and input signals from the right 
represent information flows to and from FE4. 



£75/ 



35 



ETSI TS 101 990 VI. 1.1 (2001-09) 
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Figure 15: SMS, SDL of Functional Entity 3 (shieet 1 of 2) 
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FE3_ 
AwaitAlert 



rc_ScAlert 
req/ind 



rc_ScAlert 
resp/conf 



rcSmsDeliver 
req/ind 



312 



302 



FE3_Deliver 
Invoked 



Figure 16: SMS, SDL for Functional Entity 3 (sheet 2 of 2) 
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7.4.4 Behaviour of FE4 
7.4.4.1 Message Centre case 

Figures 17 and 18 show the normal behaviour of FE4. Output signals to the left and input signals from the left represent 
information flows to and from FE3. Output signals to the right and input signals from the right represent information 
flows to and from FE7. 



FE4_ldle 



rc_SmsDeliver 
req/ind 



403 



rc_SmsDeliver 
resp/conf 



404 



rc_ScAlert 
resp/conf 



410 



rc_SmsDeliver 
req/ind 



rc_SmsDeliver 
resp/conf 



rc_ScAlert 
resp/conf 



^"^ 
'' 



FE4_ldle 



Figure 17: SMS, SDL of Functional Entity 4 - lUlessage Centre case (shieet 1 of 2) 



FE4_ldle 
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re SmsDeliverError , 



req/ind 



408 



rc_ScAlert 
req/ind 



rc_SrrsDeliverError 

req/ind 



FE4_ldle 



Figure 18: SIVIS, SDL of Functional Entity 4 - IVIessage Centre case (sheet 2 of 2) 
7.4.4.2 Terminal case 

Figure 19 shows the normal behaviour of FE4. Output signals to the left and input signals from the left represent 
information flows to and from FE3. Output signals to the right and input signals from the right represent information 
flows to and from FES or internal primitives. 
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FE4_ldle 



rc_Sms Deliver 
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Figure 19: SMS, SDL of Functional Entity 4, Terminal case 
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7.4.5 Behaviour of FES 

Figure 20 shows the normal behaviour of FES. Output signals to the left and input signals from the left represent 
information flows to and from FE4. Output signals to the right and input signals from the right represent information 
flows to and from the Receiving User. 



FE5 Idle 



rd_SmsDeliver 
req/ind 



save Short Message 
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rd_SmsDeliverError 

req/ind 



502 



FE5 Idle 



Figure 20: SMS, SDL of Functional Entity 5 
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7.4.6 Behaviour of FE6 

Figure 21 shows the normal behaviour of FE6. Output signals to the left and input signals from the left represent 
information flows to and from the Sending User. Output signals to the right and input signals from the right represent 
information flows to and from FE3. 
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Figure 21 : SMS, SDL of Functional Entity 6 

7.4.7 Behaviour of FE7 

Figure 22 shows the normal behaviour of FE7. Output signals to the left and input signals from the left represent 
information flows to and from FE4. Output signals to the right and input signals from the right represent information 
flows to and from the Receiving User. 
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FE7_ldle 
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Figure 22: SMS, SDL for Functional Entity 7 
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7.5 Allocation of Functional Entities to physical equipment 

The allocation of FEs to physical locations as shown in table 12 shall apply. 

Table 12: Scenarios for the allocation of FEs to physical equipment 





User A 
FE1 


User A 
FE2 


User A 
FE6 


FES 


UserB 
FE4 


UserB 
FES 


UserB 
FE7 


Scenario 1 


IE 


PINX 


- 


Service Centre 


PINX 


IE 


- 


Scenario 2 


- 


- 


MC 


Service Centre 


PINX 


- 


MC 


Scenario 3 


IE 


PINX 


- 


Service Centre 


PINX 


- 


MC 


Scenario 4 


- 


- 


MC 


Service Centre 


PINX 


IE 


- 



7.6 Interworking considerations 



In the cases where FE4, FES or FE7 is in another network, information pertaining to relationship re or rd shall be passed 
as appropriate to the other network by the Service Centre. The Service Centre shall contain a mapping function which 
will map the received information flows to the appropriate information flows of the other network (e.g. GSM-SMS). 

In the cases where information is received from a FE located in another network the Service Centre shall map the 
information flows from that network (e.g. GSM-SMS) to the appropriate information flows in a PISN. 

Table 13: Scenarios for the allocation of FEs to physical equipment in the case 
of interworking with other networks 
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Annex A (normative): 
Description of PDU elements 

A.1 Class 

Indication how the message was handled at the Sending Users terminal and shall be handled at the Receiving Users 
terminal (concerning displaying, storage, acknowledging). 



A.2 Command Data 



Data relating to the action that the Sending User requests the Service Centre to perform. This Data may be part of a 
Command initiated by the Sending User. 



A.3 Command Type 



Type of action that the Sending User requests the Service Centre to perform. Command Types can be used e.g. for an 
enquiry of the status of a previously submitted SM, deletion of a previously submitted SM, etc. 



A.4 Compressed 

Indication whether the text of the Short Message is compressed or not. 

A.5 Discharge Time 

Indicates the time at which a previously submitted Short Message was: 

successfully delivered to the Receiving Users Service Control Entity; or 
attempted to deliver to the Receiving Users Service Control Entity; or 
disposed of by the Service Centre. 

A.6 More-Messages-to-Send 

Indication that there are more messages waiting in that Service Centre to be sent to that particular Receiving User. 



A.7 Priority 



Requests a delivery attempt from the Service Centre to the Receiving User irrespective of whether or not the Receiving 
User has been identified as temporarily absent or having no memory available. 
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A.8 Protocol Identifier 



This refers to a higher layer protocol or indicates interworking with a certain type of telematic device. In the case of 
interworking the sending terminal requests the SC to convert the SM into a format suitable for that Receiving Users 
terminal. 



A.9 Receiving Users Name 

This is the Receiving Users name, restrictions for name presentation shall apply accordingly. 



A.10 Receiving Users Number 

This is the Receiving Users PISN number. 



A.1 1 Reject-Duplicates 

Instructs the SC to reject or accept a Short Message already held in the Service Centre. 



A. 12 Reply-Path 



Request from the Sending User to a SC to handle a reply SM sent in response to a previously received SM. In this case 
the Sending User of the reply SM is the Receiving User of the previously sent SM. The Sending User of the previously 
sent SM is the Receiving User of the reply SM. This may happen even though this SC is not known to the receiving 
terminal. 



A. 13 Sending User's Name 

This is the Name of the Sending User, restrictions for name presentation shall apply accordingly. 



A. 14 Sending User's Number 

This is the Sending User's PISN number. 



A. 1 5 Service-Centre-Time-Stamp 

Time of Arrival of the Short Message at the Service Centre. The same time value will also be carried in the 
SmsStatusReport to the Sending User relating to this particular Short Message. This will allow the Sending User to 
associate a particular sent SM with a subsequently received Status Report by correlating the two 
Service-Centre-Time-Stamp values. 



A. 16 Short Message Number 



Short Message Reference of a previously submitted Short Message on which a specific Command shall be performed. 
This value is not identical with the Short Message Reference of the Command itself. For Command Types which are 
not for a specific Short Message this field shall be ignored when received. 
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A. 17 Short Message Reference 

This is a Reference-Number identifying the Short Message (or a Command) uniquely to the Service Centre. 

A. 1 8 Short-Message-Text 

140 octet of data containing the message text and all optional User Data Headers. 



A. 1 9 SMSC Control Parameters 



Control Parameters specifying on which condition the SC shall return a Status Report to the Sending User (e.g. after 
successful delivery of the SM to the Receiving User, due to permanent error, etc.). Status-Report- Request must be set in 
order to enable SMSC Control Parameters. 



A.20 Status 



Indicates the status of a previously submitted Short Message and certain Commands for which a Status Report has been 
requested. 



A.21 Status Report Indication 

Indication of whether or not the Sending User has requested a Status Report. 

A.22 Status Report Qualifier 

Indication of whether this Status Report is a response to a previously sent SM or Command. 



A.23 Status-Report-Request 



Request from the Sending User to the Service Centre to send a Status Report for a SM or a Command. Additionally, the 
SMSC Control Parameter may be included, indicating the conditions on which a Status Report shall be returned. 



A.24 User Data Header 

Sequence of one or more User Data Header(s). A User Data Header may be used to send a SM directly to an 
applications within the Receiving Users terminal, to transfer control information to the Service Centre or to concatenate 
Short Messages. 



A.25 Validity-Period 



Time to live for a Short Message in a Service Centre. After the expiration of the Validity Period the SM shall be deleted 
within the Service Centre and a Status Report might be returned to the Sending User. 
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